An exemplary conventional process 100 is seen in FIG. 1 for allowing a user to login to an authentication infrastructure of an operating system for a local machine. As used herein, a local machine is a computing device with an operating system, such as a personal computer, a handheld computer, a thick client device, a thin client device, a personal digital assistant, an expert system, etc. The authentication infrastructure authenticates the user using a credential in order to gain access to the computing device via its operating system, such as the WINDOWS® operating system provided by Microsoft Corporation of Redmond, Wa., USA. The authentication of a credential is intended herein to be equivalent to the authentication of a user, entity, or principal with a corresponding credential, which phrases and concepts are used herein interchangeably.
At block 102 of process 100, the operating system executes a logon program. The logon program can pass control to only one of three (3) different authentication modules. Stated otherwise, the local machine can only have one authentication module with which an authentication can be performed. In the case of the WINDOWS(® operating system (OS), the default authentication module is a Graphical Identification and Authentication module, referred to herein as a ‘GINA’. The GINA, in the WINDOWS® OS, is a module in a dynamic link library (*.dll) that implements a logon user interface for a display of a screen that includes a logon dialog box into which a user inputs a username and password. The GINA is present to authenticate the user through the operating system of the computing device by use of credentials presented by the user. The user's credentials are represented by a set of information that includes identification, and proof of identification, that is used to gain access to local and network resources.
Examples of credentials are usernames and passwords, smart cards, biometric credentials, X.509 digital certificates, and other kinds of certificates. A GINA 104 seen in FIG. 1 is a standard WINDOWS® OS module and requires a conventional interactive logon process, such as by prompting a user to enter a username and a password at a user interface 103. After GINA 104 is executing, control is passed to a Local Security Authority (LSA) module 106. The LSA module 106 accesses a local Security Accounts Manager (SAM) database 108a, each of which are local stores for logon and security information for the computing device and/or for the relevant environment. A credentials database 108b, which can be local or remote, can store credentials such as fingerprints, passwords, retinal information, face recognition information, and other biometric information that can be used to authenticate a user in conjunction with a custom GINA. The LSA module 106 can also establish a connection to access a remote credential database, a token protocol credential service, a challenge and response protocol credential service, and/or an Active Directory (AD) and Kerberos Distribution Center (KDC) 110. Kerberos is a network authentication protocol to identity users that are attempting to log on to a network and to encrypt their communications through secret-key cryptography. The AD module uses a technology that enables applications to find, use, and manage directory resources (e.g., usernames and permissions) in a distributed computing environment. From these accesses, identification and authentication is performed for a user with the user's credentials so as to determine the user's access privileges to logon to the computing device via its operating system. A successful identification and authentication will log the user on and will return control to the OS logon module 102. The user will then be logged on and can proceed to use the computing device.
A first type pass-through GINA module 112, seen in FIG. 1, is a customized identification and authentication module, such as may be written by an independent software vendor that did not develop the operating system. The first type pass-through GINA module 112 interfaces with a smart card reader 105 and also interfaces with a default original operating system GINA 114 module. The first type pass-through GINA module 112 receives credentials read by the smart card reader 105 from a smart card inserted therein. A certificate read from a smart card inserted into smart card reader 105, and any other credentials acquired from a user, can be used to identify and authenticate the user against the credentials database 108b. In this case, first type pass-through GINA module 112 allows limited modifications to be made to the process of the identification and authentication of a user, while maintaining default behavior of the identification and authentication due to the interface with the original operating system GINA 114 module.
A second type pass-through GINA module 116 is a complete replacement for the standard GINA 104 for the operating system. The second type pass-through GINA module 116 interfaces with a fingerprint reader 107. The second type pass-through GINA module 116 receives credentials read by the fingerprint reader 107 from an optically scanned finger impression. The optically scanned finger impression from a finger inserted into fingerprint reader 107, and any other credentials acquired from a user, can be used to identify and authenticate the user against the credentials database 108b. The second type pass-through GINA module 116 is a customized identification and authentication module that does not interface with a standard GINA of the OS, but rather directly interfaces with LSA 106. Unlike the first type pass-through GINA module 112, the second type pass-through GINA module 116 allows for full control of a user interface that a user sees when logging on. A typical problem, as mentioned above, is that only one of the GINA 104, the first type pass-through GINA module 112, and the second type pass-through GINA module 116 can be used with an operating system. Stated otherwise, no custom or default GINA can coexist with any other custom GINA through which the OS can log a user on to the computing device or computing environment.
In addition to the foregoing, other limitations with custom GINAs can arise, such as in implementing any new credential gathering mechanism or a change thereto (e.g., for biometrics, smart cards, tokens, etc.) in order to access an operating system of a computing device. As such, custom GINAs place a significant coding burden on a developer. To implement the new or changed credential gathering mechanism, the developer has to write a new authentication model for authenticating a user who wishes to gain access to the computing device. In the case of the WINDOWS® OS, the developer must write a major revision to a custom GINA that includes complex interface and state management code so that the custom GINA can interact directly with system components of the OS. Poor coding in the custom GINA can undermine the robustness of the OS.
The replacing of the custom or default GINA is particularly sensitive in that it is one of the most vital security components of the OS. A poorly replaced GINA can greatly weaken the robustness of the OS and can reduce pre-existing functionality. The complexity of developing a replacement or custom GINA may also require the developer to obtain the underlying source code for the standard GINA of the OS. Furthermore, deploying a custom GINA means replacing the default GINA because two credential gathering methods (e.g., GINAs) cannot not coexist on the same computing device. This prevents independent software vendors from building solutions that are deployable anywhere to allow users to logon with more than one authentication infrastructure. It would be an advantage in the art to provide a logon solution that allowed users to log into different, coexisting authentication infrastructures, such as through a selectable network session, where the logon solution overcomes the aforementioned problems.